Name | Modified | Size | Downloads / Week |
---|---|---|---|
Parent folder | |||
Documentation | 2021-06-12 | ||
Library | 2021-06-12 | ||
Source Code | 2021-06-12 | ||
Tools | 2021-06-12 | ||
README.txt | 2021-06-12 | 3.4 kB | |
Totals: 5 Items | 3.4 kB | 0 |
eBus 5.6.0 Downloads Release 5.6.0 provides the following changes: + Added ERequestFeed.ERequest.cancel() method. Method ERequestFeed.ERequest.close() unilaterally cancels a request and does not allow the replier to reject the cancellation. ERequestFeed.ERequest.cancel() allows a replier the opportunity to accept or reject the cancel request. If rejected the request remains active and the replier continues processing the request. *** NOTE *** This optional cancel request feature required a change to the EReplier and CancelRequestCallback interfaces in net.sf.eBus.client package. A second parameter "boolean mayRespond" is added to the cancelRequest and call methods. This means that interface implementations must be modified to include this second parameter. Parameter "mayRespond" is set to true when ERequestFeed.ERequest.cancel() method is called and false for ERequestFeed.ERequest.close(). + Added "boolean mayClose" element to @EReplyInfo annotation. If set to true (default value) then ERequestFeed.ERequest.close() may be used to unilaterally cancel a request. If set to false then ERequestFeed.ERequest.close() may *not* be used to cancel an active request. ERequestFeed.ERequest.cancel() may always be used to cancel an active request. + Added to optional fields to net.sf.eBus.messages.ENotifificationMessage: public final long publisherId public final int position publisherId is an application-assigned value used to uniquely identify which EPublisher generated a given ENotification. The application is entirely responsible for this value, its uniqueness, and meaning. publisherId defaults to zero. position is provided to help assure notification ordering when put into and retrieved from persistent store. The problem is that message timestamps are taken from wallclock time which has a given accuracy or granularity (fox example 100 microseconds). If a publisher generates more than one notification in a given 100 microsecond period which are persisted, then the notification ordering may be lost when retrieved. The solution is for the publisher to assign a position to the notification which is starts at zero and is incremented every time a new notification is generated. This position is reset once a second. This position may then be used to maintain the notification ordering when retrieved. If notification publishing is greater than wallclock granularity then position is not needed. position defaults to zero. + Code clean-up and test coverage expansion continuing. There are four download folders: + Library: contains the eBus API jar files. + Documentation: contains the eBus Programmer's Manul in PDF and Javadoc folders in tar, gzipped and zip formats. + Source Code: snapshot of eBus maven project files at release time. + Tools: contains the eBus GUI application and configuration file needed to run the application. Note: eBus requires Java 8. *** ATTENTION ***: eBus will be moving on to Java 11 in the coming later this year (2021) or early next year. Please be aware of this change and plan accordingly.